LEAP: A Learning Apprentice for VLSI Design

It is by now well-recognised that a major impediment to developing know ledge-based systems is the knowledge acquisit ion bott leneck the task of bui lding up a complete enough and correct enough knowledge base to provide high-level performance. Th is paper proposes a new class of knowledge-based systems designed to address this knowledge-acquisition bottleneck by incorporat ing a learning component to acquire new knowledge through experience. In part icular, we define Learning Apprentice Systems as the class of interactive knowledge-based consultants that d i rect ly assimilate new knowledge by observing and analyzing the problem solving steps contributed by their users through their normal use of the system. This paper describes a specific Learning Apprent ice System, called L E A P , which is presently being developed in the domain of V L S I design We also discuss design issues for Learning Apprentice Systems more generally, as wel l as restr ict ions on the generality of our current approach I L e a r n i n g A p p r e n t i c e S y s t e m s It is by now well-recognised that a major impediment to developing knowledge-based systems is the knowledge acquisit ion bott leneck: the task of bui lding up a complete enough and correct enough knowledge base to provide high-level performance. In an effort to reduce the cost and increase the level of performance of current know ledge-based systems, a number of researchers have developed semi-automated tools for aiding in the knowledge acquisi t ion process. These tools include interact ive aids to help p inpo in t and correct weaknesses in exist ing sets of rules (e.g., | 1 , 2]) , as wel l as aids for the acquisit ion of new rules (e.g., |S|). Others have studied the automated learning of rules f rom databases of stored cases, but w i t h few exceptions (e.g., |4, 5]), work on machine learning has not yet led to useful knowledge acquisit ion tools. Th is paper proposes a new class of know ledge-based consul tant systems designed to overcome the knowledge acquisi t ion bott leneck, by incorporat ing recently developed machine learning methods to automate the acquisition of new rules. In par t icu lar , we define Learning Apprentice Systems as the class of interactive knowledge-based consultants that direct ly assimilate new knowledge by observing and analyzing the problem solving steps cont r ibu ted by their users through their normal use of the system. Th is paper discusses issues related to the development of •This material is bated on work supported by the Defense Advanced Research Projects Agency under Research Contract N0O014-81-K-0394, and by the National Science Foundation under grant DCS83-51523. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency, the National Science Foundation, or the U.S. Government. such Learning Apprent ice Systems, focusing on the design of a part icular Learning Apprent ice System (called LEAF*) for V L S I c i rcui t design. One key aspect of Learning Apprent ice Systems as we define them is that they are designed to cont inual ly acquire new knowledge w i thout an expl ic i t " t ra in ing mode". For example, the L E A P system provides advice on how to refine the design of a V L S I c i rcui t , whi le a l lowing the user to override th is advice and to manual ly refine the c i rcui t when he so desires. In those cases where the user manual ly refines the c i rcu i t , L E A P records this problem solving step as a t ra in ing example of some rule tha t it should have had. L E A P then generalizes f rom this example to form a new rule summar is ing this ref inement tact ic. In task domains for which Learning Apprent ice Systems are feasible, we expect tha t they w i l l offer strong advantages over present architectures for knowledge-based systems. Many copies of n Learning Apprent ice System d is t r ibuted to a broad communi ty of users could acquire a base of problem-solv ing experience very large compared to the experience f rom which a human expert learns For example, by d is t r ibu t ing copies of L E A P to a thousand c i rcui t designers, the system (collection) would quickly be exposed to a larger number of example c i rcui t designs than a human designer could hope to see dur ing a l i fe t ime. Such a large experience base would offer the potent ia l for acquir ing a very strong knowledge base, provided effective learning methods can be developed. The fo l lowing section describes the design of the L E A P Learning Apprent ice system for VLS I design, focusing on i ts mechanism for captur ing t ra in ing examples, and on its methods for generalizing f rom these examples to form new rules. The f ina l section discusses some of the major choices made in the in i t i a l design of L E A P , l im i ta t ions on the app l icab i l i t y of our i n i t i a l approach, and several basic issues tha t we see as central to developing Learn ing Apprent ice Systems in a var ie ty of task domains. I I L E A P : A L e a r n i n g A p p r e n t i c e f o r V L S I D e s i g n L E A P is cur rent ly being constructed as an augmentat ion to a knowledge-based V L S I design assistant called V E X E D |6|. V E X E D provides interact ive aid to the user in imp lement ing a c i rcu i t given i ts func t iona l specif ications, by suggesting and car ry ing out possible ref inements to the design. A large par t of i ts knowledge about c i rcui t design is composed of a set of implementation rules, each of which suggests some legal method for ref in ing a given func t ion . For example, one imp lementa t ion rule states tha t IF the required function is to convert a parallel signal to a serial signal, THEN one possible implementation it to 574 T. Mitchell et al. A. The V E X E D Design Consultant VEXED is a prototype knowledge-based design consultant that provides a convenient editor and user interface which helps the user design digital circuits beginning with their functional specifications and leading to their implementation. VEXED maintains an agenda of design subtasks (e.g., "implement the module that must multiply two numbers") which initially contains the top-level task of implementing the entire circuit. VEXED repeatedly selects a subtask from the agenda, examines its implementation rules to determine whether it can suggest possible implementations for the corresponding circuit module, then presents any such suggestions to the user. The user may select one of the suggested implementation rules, in which case that rule is executed to refine the module Alternatively, the user may disregard VEXED's suggestions and instead use the editor to manually refine the circuit module. It is in this later case that LEAP wil l add to its knowledge of circuit design, by generalizing from the implementation step contributed by the user to formulate a new rule that summarizes a previously uncatalogued implementation method. As an example of this kind of learning scenario, suppose that at some point during the design VEXED and the user are considering the task of implementing a particular circuit module. In the present example, this circuit module must compute the boolean product of sums of four particular input signals which appear in the context of the larger circuit. Assume further that these input signals are regular streams of boolean values arriving every 100 nanoseconds, remaining stable for approximately 70 nanoseconds, and encoded in positive logic**. Assume furthermore, that the stream of input values for Inputl is known to be an alternating stream of logical ones and zeros. The exact definitions of the function to be implemented and of the signals for which it must work are given in the top half of figure I I l * * * . Given this i n fo rmat ion about the module to be implemented, the system searches i ts set of implementa t ion rules for advice regarding possible ref inements of this c i rcu i t In this case, the system may have a rule tha t suggests imp lement ing the c i rcu i t module using an A N D gate and two OR gates. Suppose, however, tha t the user disregards the advice of the system in th is case, choosing instead to implement the module using the c i rcu i t shown in f igure I I 1 . Th is implementa t ion cont r ibuted by the user provides the system w i t h precisely the k ind of t ra in ing example t ha t L E A P needs for learning a new implementat ion ru le . In general, then , each t ra in ing example consists of (1) a descr ipt ion of the func t ion to be implemented, (2) a descript ion of the known characterist ics of the input signals, and (3) a c i rcui t entered by the user to implement the given funct ion for the given inpu t s igna ls . * * * * Given such a t ra in ing example, there are two kinds of changes that one m igh t expect the system to make to its knowledge base. F i rs t , L E A P has the oppo r tun i t y to acquire a new imp lementa t ion rule that can be used in subsequent cases to suggest the user's NOR-gate c i rcu i t where it is a potsiblc imp lementa t ion . Second, the system also has an oppor tun i t y to learn a f ragment of contro l knowledge for selecting between the NOR-gate implementat ion and the previously known A N D O R gate imp lementa t ion , depending on which is preferred according to some cost cr i ter ion. In V E X E D , we have cleanly separated out these two kinds of knowledge. Imp lementa t ion rules characterise only the possible correct implementat ions, whi le a separate body of control knowledge w i l l be used to select the **That is, a logical one is encoded as five volts, and a logical sero ai sero volts. ***Signals, or "datastreams" In VEXED are described as an array of data elements, each defined in terms of its Value, Start-Time, Duration, Datatype, and Encoding. ••**Although in this example the user's circuit has been refined down to the gate level, in general it need only be one step more refined than the sub-module it is implementing. T. Mitchell et al. 575 Given this t ra in ing example, the most s t ra ight forward method of acquir ing a new implementat ion rule is to create a ru le tha t suggests the given circuit, can be used to implement the given module funct ion in precisely this context (e.g., whenever the inpu t signals are precisely the same as in the t ra in ing example). Such a rule wou ld clearly be so specific that it wou ld add l i t t l e of general use to the system's knowledge of imp lementa t ion methods. A better approach would be to generalise the precondi t ions (left hand side) of the implementat ion rule, so that i t characterises the general class of inpu t signals for which the given c i rcu i t correct ly implements the specified funct ion. Such a generalised ru le is shown in f igure I I -2 and the method for produc ing such generalizations in L E A P is described in the fo l lowing subsection. A fur ther step in generalizing the imp lementa t ion rule wou ld be to generalize the user's c i rcui t as wel l as the func t ion it implements. (e.g., the essential idea behind the NOR-ga te imp lementa t ion can be used to implement a class of funct ions related to the one encountered in this t ra in ing example). Such a general izat ion of the implementat ion rule is shown in f igure I I -3 , and the method used by L E A P for generalizing the rule in this fashion is described in subsection 2.3 B . G e n e r a l i z i n g t h e R u l e L e f t H a n d S ide L E A P computes a jus t i f iab ly general rule precondit ion by using i ts theory of d ig i ta l c ircui ts to analyze the single t ra in ing example. In part icular, L E A P f i rst explains (verifies) for itself tha t the circui t does in fact work for the example input signals, then generalizes f rom this example by retain ing only those features of the signals that were mentioned in this explanat ion. It is th is set of signal features that is required for the explanat ion to hold in general, and which therefore characterizes the class of inpu t signals for which the c i rcui t w i l l correctly implement the desired func t ion . Th is explain-then-generalise method for producing jus t i f iab le generalizations f rom single examples is based on our previous work on goal-directed generalization [7|, and is also s imi lar to the generalization methods employed in [8, 9, 10]. To i l lustrate this generalisation method, consider again the t ra in ing example introduced above in f igure I I 1 . L E A P begins by ver i fy ing that the example c i rcu i t w i l l operate correctly for the example input signals. In order to do th is , i t examines its def in i t ions of the pr im i t i ve components tha t make up the example c i rcui t . Figure 2-4 shows the descr ipt ion of the p r im i t i ve NOR gate used in the present example c i rcui t . The Operating Conditions in this description summarise characteristics of the input signals tha t are required for the component to have a well defined ou tpu t . For example, the constra int " (Length (Intersection (Interval Input1(i)) (Interval Inputt(i)))) > S nsec." indicates tha t for the NOR gate to operate correct ly, i ts inputs 576 T. Mitchell et al. inputs Input 1. Input2 Outpu ts Output Operat ing Condi t ions (Equals (Datatype I n p u t l ( i ) ) Boolean) (Equals (Encoding Inpu t1 ( i ) ) Posit ive-Logic) (Equals (Datatype l n p u i 2 ( i ) ) Boolean) (Equals (Encoding l n p u t 2 ( i ) ) Posit ive-Logic) (Length (Intersection ( In terva l I n p u t l ( i ) ) ( In terva l l npu t2 ( i ) ) ) ) > S nsec. Mapp ing . (Equals (Value O u t p u t ( i ) ) (Not (Or (Value I n p u t l ( i ) ) (Value Inpu t2 ( i ) ) ) ) ) (Equals (Encoding O u t p u t ( i ) ) Posit ive-Logic) (Equals (Star t -T ime O u t p u t ( i ) ) (+ 10 (Latest (S ta r t -T ime I n p u t l ( i ) ) (S ta r t -T ime l npu t2 ( i ) ) ) ) ) (Equals (Dura t ion O u t p u t ( i ) ) (Length (Intersect ion ( In te rva l I n p u t l ( i ) ) ( In terva l I npu t2 ( i ) ) ) ) ) The Operating Conditions describe m i n i m u m requirements on input signals to assure the component w i l l produce a well-defined ou tpu t . The Mapping describes how features of the ou tpu t signal depend on the inputs . F i g u r e I I 4 : K n o w n B e h a v i o r o f a N O R G a t e . must over lap in t ime by at least 3 nanoseconds***** . These Operat ing Condi t ions of the ind iv idua l c i rcu i t components are constraints tha t must be verif ied for the example c i rcui t and the given inpu t signals. Some of these operat ing condi t ions can be tested d i rect ly against the descript ions of the global c i rcu i t inputs (e.g., the operat ing condi t ions for the leftmost N O R gates in the example c i rcui t can be tested against the known characterist ics of the c i rcui t inputs) . The operat ing condi t ions associated w i t h components in terna l to the example c i rcui t must be restated in terms of the equivalent constra ints on the global c i rcu i t inputs . These constraints are therefore propagated to (reexpresaed in terms of) the global inputs of the c i rcui t ne twork , then tested to see tha t they are satisfied by the example inpu t signals. For instance, the constraint "(Length (Intersection (Interval X(i)) (Interval Y(i)))) > S nsec.* wh ich fol lows f r om the operat ing condi t ions of the r ight -most N O R gate, is reexpresaed in terms of the four global c i rcui t inputs to produce the equivalent const ra in t "(Length (Intersection (Interval Input1(i))( Interval Input2(i))( Interval Input3 (i))(Interval Input4(i)))) > S nsec.,".****** By propagat ing the constra ints arising f r o m the operat ing condi t ions of the c i rcu i t components, as we l l aa the or ig ina l constra int on the c i rcui t ou tpu t (e.g., t ha t *****The Initial of a data element is defined here as the time interval beginning at the Start Time of the data element, and continuing for the Duration of that data element. * * * * * *Th is constraint propagation step is performed in the VEXED system by a set of routines called CRITTER [11) which is able to propagate and check signal constraints in loop-free digital circuits, by examining the function definitions of the primitive circuit elements. it produce the . .. i U P ..l ,.. i » I ih> inputs) | | \ | ' . „, venfy that the user-imr«>du<rd U P U I I w i l l correctly implement the desired funct ion for the given inputs More impo r tan t ) ) the constraints that are propagated to the inputs of the circuit network characterize precisely the class of inputs for which the c i rcui t w i l l operate correct ly, and therefore const i tu te the desired general precondit ions for the newly acquired imp lementa t ion rule. In summary , the procedure for comput ing the generalized precondit ions for the new rule is to (1) propagate each constra int derived f rom the operat ing condi t ions of each p r i m i t i v e c i rcu i t component, along w i t h constraints on the global c i rcu i t ou tpu t , back to the global inputs to the c i rcu i t network, then to (2) record the result ing constraints on the global inpu ts , w i t h appropriate subst i tu t ion of var iable names, as the generalized precondit ions for the new imp lementa t ion ru le. F igure I I -2 i l lustrates the resul t ing general ization for the t r a i n i ng example f rom f igure I I 1 . Not ice that in compar ing this generalized rule w i t h the or ig ina l t ra in ing example, values of several features of the c i rcui t inputs have been generalized Only the constraints on Data type and on Signal-Encodings remain in tac t , wh i le the detai led values for the signal S tar t -T imes and Dura t ions have been replaced by the general constra int on over lapping t ime intervals. C . G e n e r a l i s i n g R u l e R i g h t H a n d S i d e The previous section describes how L E A P is able to generalize the lef t -hand side (LHS) of the rule by determin ing the class of input signals for which the given c i rcu i t w i l l work Th i s section describes how L E A P can also generalize the r igh t -hand side (RHS) of the rule; tha t is, generalize the circui t schematic along w i t h the funct iona l specifications to be implemented The key to generalizing the RHS is to f i rst ver i fy t ha t the c i rcui t correctly implements the desired func t ion . Th i s ver i f icat ion can then be examined to determine the general class of circuits and funct ional specif ications to wh ich the same ver i f icat ion steps w i l l apply. Th is method, wh ich we cal l Ver i f icat ion-Based Learn ing, is described more generally in [12|. T h a t paper discusses the general app l icab i l i t y of th is method to learning problem-decomposi t ion rules, or p lann ing schema. Here we discuss the appl icat ion of this method to general izing c i rcu i t implementat ion rules, and i l lust rate the method using the t ra in ing example and rule discussed above. 1 . S t e p 1 : F o r m i n g t h e C o m p o s e d S p e c i f i c a t i o n f r o m R u l e R H S The f i rst step in the process of in ferr ing a general c i rcu i t design rule f rom a t ra in ing example is tha t of ver i f i ca t ion : ensuring tha t the funct ion computed by the user's c i rcu i t meets the or ig inal c i rcu i t specif icat ion. We can derive a descr ipt ion of the c i rcu i t 's func t ion f r o m its st ructure by composing the funct ions of the submodules const i tu t ing the c i rcu i t , according to the conf igurat ion in wh ich they are interconnected. For the user's NOR-ga te c i rcu i t , th is composed specification is given as T. Mitchell et al. 577 Note tha t , in general, the composed specif ication w i l l be a syntactically reexpressed version of the or iginal specif icat ion. For example, the above composed specification is not syntact ica l ly ident ical to the funct ional specifications* in the t ra in ing example, even though it does represent the same boolean func t ion . Th is frequently occurs in VLS I circuits in wh ich , for example, funct ional specifications in terms of A N D and OR boolean expressions are often implemented in terms of N A N D and N O R gates. 2 . S t e p 2 : V e r i f y i n g t h e C i r c u i t F u n c t i o n To verify the correctness of the user-suggested NOR-gate c i rcui t , L E A P must show the equivalence between the composed specification for this circuit and the original specification of the circui t being implemented. Thus, i t seeks to veri fy tha t